Requirements Engineering Tasks

Many managers and others who are not professional requirements engineers tend to greatly oversimplify requirements engineering (RE). Based on their observations that requirements specifications primarily contain narrative English textual statements of individual requirements and that all members of the engineering team are reasonably literate, there is a common myth that practically anyone with little or no specialized training or expertise can be a requirements engineer. After all, what is there to do but ask a few stakeholders what they want (requirements elicitation), study the resulting requirements to make sure they are understood (requirements analysis), write the requirements down in a document (requirements specification), and then ask the customer if they're right (requirements validation). Just give the team a short class in use case modeling, and they are ready to go. Unfortunately, the preceding is a misleading, if much too prevalent, myth. While these four RE tasks (not sequential phases!) are commonly performed with varying degrees of completeness, rigor, and success on most projects, a list of tasks containing only these four is far from complete. The purpose of this paper is to provide a brief introduction to all of the major tasks comprising RE, as well as to three essential and highly related tasks from the management, configuration management, and quality engineering disciplines. Depending on the topmost goals of the system development project or product line development projects, the RE teams need to ensure that the actual RE method to be used contains all of the essential and cost-effective RE tasks, tailored to meet the specific needs of the endeavor. Although not the primary topic of this paper, a brief word must be said about the makeup of the RE teams that will be performing the requirements engineering tasks. Because of the criticality of the requirements and the breadth of their scope and impact, each RE team clearly must be cross-functional to be effective. In addition to requirements engineers, the RE teams need to either include or collaborate closely with domain experts and a representative sample of key stakeholders such as customer representatives, marketing, business analysts, user representatives, system architects to ensure requirements feasibility, system testers to ensure requirements verifiability, etc.